1. Field of the Invention
This invention generally relates to wireless communication systems, and more particularly to a system and method for performing a serving radio network sub-system (SRNS) relocation procedure in a communications system.
2. Background of the Related Art
A universal mobile telecommunications system (UMTS) is a third generation mobile communication system that has evolved from a standard known as Global System for Mobile communications (GSM). This standard is a European standard which aims to provide an improved mobile communication service based on a GSM core network and wideband code division multiple access (W-CDMA) technology. In December, 1998, the ETSI of Europe, the ARIB/TTC of Japan, the T1 of the United States, and the TTA of Korea formed a Third Generation Partnership Project (3GPP) for the purpose of creating a specification for standardizing the UMTS.
The work towards standardizing the UMTS performed by the 3GPP has resulted in the formation of five technical specification groups (TSG), each of which is directed to forming network elements having independent operations. More specifically, each TSG develops, approves, and manages a standard specification in a related region. Among them, a radio access network (RAN) group (TSG-RAN) develops a specification for the function, items desired, and interface of a UMTS terrestrial radio access network (UTRAN), which is a new RAN for supporting a W-CDMA access technology in the UMTS.
The TSG-RAN group includes a plenary group and four working groups. Working group 1 (WG1) develops a specification for a physical layer (a first layer). Working group 2 (WG2) specifies the functions of a data link layer (a second layer) and a network layer (a third layer). Working group 3 (WG3) defines a specification for an interface among a base station in the UTRAN, a radio network controller (RNC), and a core network. Finally, Working group 4 (WG4) discusses terms desired for a radio link performance and items desired for radio resource management.
FIG. 1 shows a structure of a 3GPP UTRAN to which the present invention may be applied. This UTRAN includes one or more radio network sub-systems (RNS). Each RNS includes an RNC and one or more Nodes B (e.g., a base station) managed by the RNCs. RNCs are connected to a mobile switching center (MSC) which performs line exchange communications with the GSM network. The RNCs are also connected to a serving general packet radio service support node (SGSN) which performs packet exchange communications with a general packet radio service (GPRS) network.
Nodes B are managed by the RNCs, receive information sent by the physical layer of a terminal (e.g., mobile station, user equipment and/or subscriber unit) through an uplink, and transmit data to a terminal through a downlink. Nodes B, thus, operate as access points of the UTRAN for the terminal.
The RNCs perform functions which include assigning and managing radio resources. An RNC that directly manages a Node B is referred to as a control RNC (CRNC). The CRNC manages common radio resources. A serving RNC (SRNC), on the other hand, manages dedicated radio resources assigned to the respective terminals. The CRNC can be the same as the SRNC. However, when the terminal deviates from the region of the SRNC and moves to the region of another RNC, the CRNC can be different from the SRNC. Because the physical positions of various elements in the UMTS network can vary, an interface for connecting the elements is necessary. Nodes B and the RNCs are connected to each other by an Tub interface. Two RNCs are connected to each other by an lur interface. An interface between the RNC and a core network is referred to as Iu.
Services provided to the UE may generally be classified into circuit-switching services and packet-switching services. A voice telephone service may be included in the circuit-switching service and a Web-browsing service may be included in a packet-switching service through an Internet connection. The circuit-switching service is connected to an MSC of the core network, and this MSC is connected to a gateway mobile switching center (GMSC) for communicating with one or more external networks. The GMSC manages the connections between the MSC and the external networks.
The packet-switching service is connected to a serving general packet radio service (GPRS) support node (SGSN), this node is connected to a gateway GPRS support node (GGSN) of the core network. The SGSN communicates packets between the SRNC and GGSN, and the GGSN manages connections between the SGSN and another packet-switching network such as the Internet.
A variety of interfaces are provided for performing mutual data exchanges between these network components. An interface between an RNC and the core network is known as an Iu interface. When the Iu is connected to the packet-switching domain, it is called an Iu PS interface, and when the Iu is connected to the circuit-switching domain it is called a Iu CS interface.
FIG. 2 shows a structure of a radio access interface protocol between a terminal which operates based on a 3GPP RAN specification and a UTRAN. The radio access interface protocol is horizontally formed of a physical layer (PHY), a data link layer, and a network layer and is vertically divided into a control plane for transmitting control information and a user plane for transmitting data information. The user plane is a region to which traffic information of a user such as voice or an IP packet is transmitted. The control plane is a region to which control information such as an interface of a network or maintenance and management of a call is transmitted.
In FIG. 2, protocol layers can be divided into a first layer (L1), a second layer (L2), and a third layer (L3) based on three lower layers of an open system interconnection (OSI) standard model well known in a communication system. The first layer (L1) operates as a physical layer (PHY) for a radio interface and is connected to an upper medium access control (MAC) layer through one or more transport channels. The physical layer transmits data delivered to the physical layer (PHY) through a transport channel to a receiver using various coding and modulating methods suitable for radio circumstances. The transport channel between the physical layer (PHY) and the MAC layer is divided into a dedicated transport channel and a common transport channel based on whether it is exclusively used by a single terminal or shared by several terminals.
The second layer L2 operates as a data link layer and lets various terminals share the radio resources of a W-CDMA network. The second layer L2 is divided into the MAC layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a broadcast/multicast control (BMC) layer.
The MAC layer delivers data through an appropriate mapping relationship between a logical channel and a transport channel. The logical channels connect an upper layer to the MAC layer. Various logical channels are provided based on the kind of transmitted information. In general, when information of the control plane is transmitted, a control channel is used. When information of the user plane is transmitted, a traffic channel is used. The MAC layer is divided two sub-layers according to performed functions. The two sub-layers are a MAC-d sub-layer that is positioned in the SRNC and manages the dedicated transport channel and a MAC-c/sh sub-layer that is positioned in the CRNC and manages the common transport channel.
The RLC layer forms an appropriate RLC protocol data unit (PDU) suitable for transmission by the segmentation and concatenation functions of an RLC service data unit (SDU) received from an upper layer. The RLC layer also performs an automatic repeat request (ARQ) function by which an RLC PDU lost during transmission is re-transmitted. The RLC layer operates in three modes: a transparent mode (TM), an unacknowledged mode (UM), and an acknowledged mode (AM). The mode selected depends upon the method used to process the RLC SDU received from the upper layer. An RLC buffer stores the RLC SDUs or the RLC PDUs received from the upper layer. A more detailed explanation of the modes of operation of the RLC layer will follow.
The packet data convergence protocol (PDCP) layer is an upper layer of the RLC layer which allows data items to be transmitted through a network protocol such as IP.v4 or IP.v6. A header compression technique for compressing and transmitting the header information in a packet can be used for effective transmission of the IP packet.
The broadcast/multicast control (BMC) layer allows a message to be transmitted from a cell broadcast center (CBC) through the radio interface. The main function of the BMC layer is scheduling and transmitting a cell broadcast message to a terminal. In general, data is transmitted through the RLC layer operating in the unacknowledged mode.
The PDCP layer and the BMC layer are connected to the SGSN because a packet exchange method is used, and are located only in the user plane because they transmit only user data. Unlike the PDCP layer and the BMC layer, the RLC layer can be included in the user plane and the control plane according to a layer connected to the upper layer. When the RLC layer belongs to the control plane, data is received from a radio resource control (RRC) layer.
In general, the transmission service of user data provided to the upper layer by the second layer (L2) in the user plane is referred to as a radio bearer (RB). The transmission service of control information provided to the upper layer by the second layer (L2) in the control plane is referred to as a signaling radio bearer (SRB). As shown in FIG. 2, a plurality of entities can exist in the RLC and PDCP layers. This is because a terminal has a plurality of RBs, and one or two RLC entities and only one PDCP entity are generally used for one RB. The entities of the RLC layer and the PDCP layer can perform an independent function in each layer.
The RRC layer positioned in the lowest portion of the third layer (L3) is defined only in the control plane and controls the logical channels, the transport channels, and the physical channels in relation to the setting, the re-setting, and the cancellation of the RBs. At this time, setting up the RB means processes of stipulating the characteristics of a protocol layer and a channel, which are required for providing a specific service, and setting the respective detailed parameters and operation methods. It is possible to transmit control messages received from the upper layer through a RRC message.
Operation of the radio bearer and the RLC layer will be now described in detail. As previously discussed, a radio bearer (RB) is a transmission service which delivers user data in the user plane to an upper layer through the second layer L2. The transmission service which delivers control information in the control plane to the upper layer through the second layer L2 is defined as a signaling radio bearer (SRB).
As previously noted, the RLC layer operates in one of three modes: transparent mode (ITM), unacknowledged mode (UM), and acknowledged mode (AM).
When operating in the TM mode, header information is not added to the RLC SDU received from the upper layer, no sequence number is attached to the RLC PDU and data re-transmission is not performed. Also, though segmentation and reassembly of the RLC SDU are generally not performed, use of segmentation and reassembly when the radio bearer is set up is determined in certain circumstances.
When operating in UM mode, re-transmission of RLC PDUs is not performed even when a transmission failure occurs. The receiver does not request retransmission of data. Instead, a different approach is taken. In UM mode, the RLC layer constructs RLC PDUs by segmenting or concatenating RLC SDUs, and then attaching sequence numbers to the RLC PDUs. The receiver can restore lost data based on the sequence numbers by a re-assembly procedure.
When operating in the AM mode, re-transmission is used to support error-free transmission in the following manner. Status information corresponding to received RLC PDUs is transmitted from the receiver in the form of a Status Report. After receiving this report, the transmitter re-transmits unsuccessfully transmitted RLC PDUs.
More specifically, in AM mode, the transmitter forms each RLC PDU from one or more RLC SDUs that have been received from an upper layer, and header information, (e.g. sequence number and length indicators) are then attached. Since the size of an AM RLC PDU is fixed, the transmitter segments or concatenates one or more RLC SDUs to fit the PDU size. Then, the formed RLC PDU is stored in the transmission buffer. The stored RLC PDUs are sequentially delivered to the MAC layer at a rate controlled by the MAC layer. Since each RLC PDU has its own sequence number, the receiver can check which RLC PDUs are successfully received and which are not. The receiver requests the retransmission for the unsuccessfully received RLC PDUs to the transmitter by the Status Report.
The AM retransmission procedure may be more clearly understood by the following example. If the sequence numbers of the received RLC PDUs are #23, #24, #25, #32, and #34, the receiver considers that RLC PDUs having the sequence numbers of #26 to #31 and #33 are lost during transmission. The receiver then sends a Status Report to the transmitter, and the transmitter checks the Status Report, and re-transmits the unsuccessfully transmitted RLC PDUs, i.e. #26 to #31 and #33.
FIG. 3 shows the structure of an RLC PDU of AM or UM mode used in the RLC layer. The RLC PDU is comprised of a header and a payload. The header shown includes a sequence number and a length indicator. The sequence number is used as an identifier of the corresponding RLC PDU, and the length indicator indicates a boundary of the RLC SDU. The sequence numbers may be, for example, 7 (seven) bits for UM mode, and 12 (twelve) bits for AM mode. A 1 (one) bit E field may be included to indicate whether the next field is the length indicator or data.
The length indicator is used to indicate the boundary of each RLC SDU ending within the RLC PDU. Therefore, the length indicator may not be present if the RLC SDU is not ended within the RLC PDU. The length indicator may also be used for other purposes. For example, the length indicator may be used as a padding indicator and/or a data start indicator. Padding is used to fill the whole RLC PDU when there is no RLC SDU to be concatenated. The padding can have any value and the receiver and the sender disregard it. When used as a data start indicator the length indicator may indicate that the RLC SDU begins in the beginning of the RLC PDU.
The data start indicator is useful because it can prevent additional loss of data in the UM RLC. For example, assume that an RLC PDU of sequence number #4 is lost and an RLC PDU of sequence number #5 is received. Assume further that a new RLC SDU begins at the beginning of the PDU of sequence number #5 and ends within the PDU of sequence number #5. In this case, because the RLC SDU begins at the beginning of the PDU of sequence number #5, the data start indicator is present at the header of the PDU of sequence number #5. But, if the data start indicator is not present, the receiver RLC layer considers that only continued segments of an RLC SDU contained in the RLC PDU of sequence number #5 is received. In this case, the receiver discards the segments because the receiver thinks that the entire RLC SDU has not been received.
FIG. 4 shows an exemplary snapshot of the status of an RLC buffer. As shown, the RLC PDUs are sequentially stored in the buffer and the successfully transmitted RLC PDUs are deleted from the buffer. As shown, the RLC layer uses state variables for managing the transmission of data using the RLC buffer.
When operating in AM mode, the RLC layer uses a state variable VT(S) to indicate the sequence number of the next RLC PDU to be transmitted for the first time, and a state variable VT(A) to indicate the sequence number of the first RLC PDU to be positively acknowledged by the receiver. The status of the buffer therefore indicates that the transmitter has transmitted RLC PDUs up to the PDU of sequence number of VT(S)-1 and has received positive acknowledgments up to the RLC PDU of VT(A)-1 from the receiver.
When operating in the UM mode, the RLC layer uses a state variable VT(US) which is similar to VT(S) in AM mode. That is, VT(US) indicates the sequence number of the next RLC PDU to be transmitted. However, since there is no feedback from the receiver in UM mode, the state variable such as VT(A) is not defined.
In both modes of operation, the initial value of the state variables may be set to 0 (zero). When the RLC layer is established, re-established or reset, the state variables are set to this initial value.
Returning now to radio communications protocol shown in FIG. 2, as previously indicated, the service provided to the upper layer by the second layer L2 in the control plane is defined as a signaling radio bearer (SRB). In operation, all RRC messages are exchanged between the terminal and the RNC through the signaling radio bearers SRBs. Using the RRC messages, the RNC can setup, modify, and release the radio bearers as needed in order to, for example, perform an SRNS relocation procedure, the details of which are described in greater detail below.
Signaling radio bearer (SRB) characteristics as previously indicated are determined based on the mode of operation of the RLC and the type of logical channel used. A common control channel (CCCH) and dedicated control channel (DCCH) are used for the SRBs. CCCH is a logical channel carrying common control information to several terminals. Since CCCH is a common logical channel, CCCH contains a UTRAN radio network temporary identity (U-RNTI) to identify a specific terminal. The DCCH is a logical channel carrying dedicated control information to a specific terminal.
The characteristics of each type of SRB are as follows.
SRB0: For the uplink (UL) TM RLC is used, and for the downlink (DL)UM RLC is used. The logical channel used for the SRBO is CCCH.
SRB1: UM RLC is used, and the logical channel is DCCH.
SRB2: AM RLC is used, and the logical channel is DCCH. The SRB2 carries only the messages generated in the RRC layer. The SRB2 does not carry the upper layer messages.
SRB3: AM RLC is used, and the logical channel is DCCH. The SRB3 carries the messages received from the upper layer.
SRB4: AM RLC is used, and the logical channel is DCCH. The SRB4 also carries the messages received from the upper layer. The difference is that the SRB3 carries higher priority messages while the SRB4 carries lower priority messages.
SRB5-31: TM RLC is used, and the logical channel is DCCH. These SRBs are optionally used.
SRNS Relocation Procedure
FIG. 5 is a diagram showing how a serving radio network sub-system (SRNS) procedure may be performed in a packet-switching based service domain. As shown, this procedure involves changing the RNS serving a user terminal from one RNS (or RNC) to another. When making this change, it is preferable to establish the shortest route between the terminal and core network by changing the Iu connection point. As is further shown, changing the Iu connection point may in some instances cause the core network to switch from one SGSN (Old SGSN) to another (New SGSN) for purposes of performing communications with the user terminal. The SRNS relocation procedure may also be performed in the circuit-switching based service domain.
An SRNS relocation procedure may be performed for at least the following reasons:                Connection Point Change: Relocation is performed to move the UTRAN to a CN connection point at the UTRAN side from the source RNC to the target RNC.        Combined Hard Handover: Relocation is performed to move the UTRAN to a CN connection point at the UTRAN side from the source RNC to the target RNC, while performing a hard handover decided by the UTRAN.        Combined Cell/URA Update: Relocation is performed to move the UTRAN to the CN connection point at the UTRAN side from the source RNC to the target RNC, while performing a cell re-selection in the UTRAN.As will be discussed in greater detail, an SRNS relocation procedure may require the use of different radio bearers depending upon the mode of operation of the RLC layer.        
SRNS relocation is usually classified into two cases: (1) terminal not involved case (Case I) and (2) terminal involved case (Case II). In Case I, SRNS relocation is initiated by a network's own decision and the terminal does not know whether the SRNS relocation is performed until the relocation procedure is terminated. In Case II, SRNS relocation is initiated as a result of the terminal's cell change (e.g., handover) request and the terminal knows the SRNS relocation at the beginning of the procedure. Though Cases I and II are different in that one is involved with the terminal and the other is not, the two cases have no substantial difference with respect to the SRNS relocation procedure. A more detailed explanation of this procedure now follows.
During the SRNS relocation procedure, various signaling messages are exchanged between the terminal and one RNC, between the one RNC and another RNC, and between one of the RNCs and the core network.
FIG. 6 shows the exchange of signaling messages that takes place between the terminal and core network in the SRNS relocation procedure of the UMTS. In this exchange, the “source RNC” is the RNC that plays the role of the SRNC before SRNS relocation and the “target RNC” is the RNC that plays the role of the SRNC after SRNS relocation. Likewise, the “old SGSN” is the SGSN before the relocation procedure and the “new SGSN” is the SGSN after the relocation procedure. Though the old and new SGSNs are shown to be different, the old SGSN and new SGSN may be the same in certain circumstances. Moreover, the procedure shown in FIG. 6 may be applied to both Case I and Case II.
The steps of the SRNS relocation procedure will now be summarized. In an initial step, step 1, the source RNC decides to perform an SRNS relocation. Either Case I or Case II may be used to trigger the relocation procedure.
In step 2, the source RNC sends a Relocation Required message to the old SGSN. The Relocation Required message includes information for performing, for example, relocation co-ordination, security functionality, RRC protocol context information, and the terminal capabilities.
In step 3, the old SGSN determines from the Relocation Required message if the SRNS relocation is intra-SGSN or inter-SGSN SRNS relocation. An intra-SGSN procedure is performed when the old and new SGSNs are the same, and an inter-SGSN procedure is performed when the two are different. A Forward Relocation Request message is applicable only in the case of inter-SGSN SRNS relocation.
In step 4, the new SGSN sends a Relocation Request message to the target RNC so that the necessary resources are allocated between the target RNC and the new SGSN. After all necessary resources are successfully allocated, the target RNC sends the Relocation Request Acknowledge message to the new SGSN.
In step 5, when a resource for the transmission of user data between the target RNC and the new SGSN have been allocated and the new SGSN is ready for SRNS relocation, the Forward Relocation Response message is sent from the new SGSN to old SGSN.
In step 6, the old SGSN continues SRNS relocation by sending a Relocation Command message to the source RNC. The source RNC is ready for forward downlink user data directly to the target RNC.
In step 7, when the source RNC is ready for data-forwarding, it triggers execution of SRNS relocation by sending a Relocation Commit message to the target RNC.
In step 8, the source RNC begins to forward data for the radio access bearers. The data forwarding may be carried out through the Iu interface, which means that data is not directly exchanged between the source RNC and the target RNC but through the core network.
In step 9, the target RNC sends a Relocation Detect message to the new SGSN. When the Relocation Detect message is sent, the target RNC starts SRNC operation.
In step 10, the target RNC sends a UTRAN mobility information (Case I) message or a Cell/URA (UTRAN registration area) update (Case II) message to the terminal. Both messages contain terminal information elements and core network information elements. The terminal information elements include new U-RNTI used for the identification of the terminal in the target RNC. The core network information elements include location area identification and routing area identification information.
Upon receipt of the UTRAN Mobility Information message the terminal can start sending uplink (UL) user data to the target RNC. When the terminal has reconfigured itself, it sends the UTRAN Mobility Information Confirm message to the target RNC. This indicates that the terminal is also ready to receive downlink (DL) data from the target RNC.
In step 11, upon receipt of the Relocation Detect message the core network switches the user plane from source RNC to target RNC. In the case of an inter-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response.
In step 12, when the target RNC receives the UTRAN Mobility Information Confirm message, (i.e., the new U-RNTI is successfully exchanged with the terminal by the radio protocols), the target RNC sends the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete message is to indicate by the target RNC completion of the relocation of the SRNS to the core network. In the case of an inter-SGSN SRNS relocation, the new SGSN signals the old SGSN of the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message.
In step 13, upon receiving the Relocation Complete message or the Forward Relocation Complete message, the old SGSN sends an Iu Release Command message to the source RNC so that the Iu connection between the source RNC and the old SGSN is released.
FIG. 7 shows the steps of the SRNS relocation procedure including the exchange of RRC messages between the UTRAN and the terminal. In this figure, RRC messages are transmitted at steps 1, 7, and 8, and the UTRAN can either be the source RNC or target RNC depending on the case. Also, UE, refers to user equipment and therefore may include a user terminal. The RRC messages transmitted in this procedure are described as follows.
(1) Cell Update message and Cell Update Confirm message: When the terminal moves to a new cell, a Cell Update message is sent from the terminal to the UTRAN. If the UTRAN decides to perform SRNS relocation, the target RNC sends the Cell Update Confirm message to the terminal as a response to the Cell Update message. The Cell Update Confirm message contains the new U-RNTI, which indicates to the terminal the SRNS relocation procedure being performed. The Cell Update message is transmitted through SRBO using TM RLC, and the Cell Update Confirm message is through either SRB0 or SRB1 using UM RLC.
(2) URA Update message and URA Update Confirm message: A URA (UTRAN registration area) is an area comprised of one or several cells, and is internally known to the UTRAN. The URAs may partially overlap in order to prevent a ping-pong effect of the terminal. Therefore, one cell can belong to one or more URAs. The terminal knows the current URA identity from the URA list broadcast in each cell and performs the URA update procedure whenever the URA is changed.
The URA update procedure is initiated when the terminal sends the URA Update message to the UTRAN. The UTRAN transmits the URA Update Confirm message in response to the URA Update message to the terminal, in order to inform the terminal of the new URA identity. The URA Update Confirm message includes a new U-RNTI which is the same as in the Cell Update Confirm message. The URA Update message is transmitted through SRB0 using TM RLC, and the URA Update Confirm message is transmitted through SRB0 or SRB1 using UM RLC.
(3) UTRAN Mobility Information message and UTRAN Mobility Information Confirm message: The UTRAN Mobility Information message is used when the UTRAN assigns a new U-RNTI to the terminal or when mobility information is transmitted. The terminal transmits UTRAN Mobility Information Confirm message in response. After successfully transmitting the UTRAN Mobility Information Confirm message, the target RNC and the terminal establish/re-establish the PDCP and RLC entities using CPDCP-CONFIG-Req and CRLC-CONFIG-Req commands, respectively. The UTRAN Mobility Information message is transmitted through SRB1 using UM RLC or SRB2 using AM RLC. The UTRAN mobility Information Confirm message is transmitted through SRB2 using AM RLC.